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1.0 Introduction 


The Fast Affordable Science and Technology Satellite (FASTSAT) project is a path finding effort to 
produce reliable satellite busses for different applications at an unprecedented speed and low cost. The 
project is designed to be a generational project and the first satellite produced is the Huntsville-01 (HSV- 
01) spacecraft. The subject of this report is the lessons learned gained during the development, testing, 
and up to the delivery of the FASTSAT HSV-01 spacecraft. The purpose of this report is to capture the 
major findings that will greatly benefit the future FASTSAT satellites and perhaps other projects 
interested in pushing the boundaries for cost and schedule. 

The FASTSAT FISV-01 primary objectives, success criteria, and team partners are summarized to give a 
frame of reference to the lessons learned. 1 

The primary objectives of the FASTSAT FISV-01 project are to provide low Earth orbit opportunities 
for the satellite experiments, to demonstrate the satellite bus and mission integration approach, 
and to demonstrate PPOD launch capability of a "nanosat" class spacecraft from the satellite bus. 

The minimum success criteria of the FASTSAT FISV-01 project are to design and develop a standard 
interface vehicle to support payload experimentation and release for an autonomous mission. The 
full success criteria are the successful operation of all experiments in space, the demonstration of 
FISV-01 as a standard interface vehicle, deployment of a "nanosat", and the identification of an 
optimized deployment Design Reference Mission (DRM) for all future flights. 

The development of the FISV-01 spacecraft is a collaborative effort between the Department of 
Defense's Space Test Program (STP), Dynetics, the Von Braun Center for Science and Innovation 
(VCSI), and the NASA Marshall Space Flight Center (MSFC). This report does not include lessons 
learned on the business model or on the agreement vehicles used to form the partnership. 

The FISV-01 spacecraft weighs approximately 149 kilograms (328 pounds), is approximately half the size 
of standard kitchen refrigerator, and includes six experiments (Figure 1). This report does not include 
lessons learned related to the development of the experiments. This report does include any lessons 
learned related to the engineering interfaces and communications practices between the FASTSAT 
spacecraft bus personnel and the experiment Principal Investigators. 

The lessons learned are divided into four topic areas: Project Management, Systems Engineering, 
Engineering, and Safety and Mission Assurance. Each lesson learned includes discussion on the finding, 
recommendations for future projects, and methods to determine if an issue is occurring. Some lessons 
learned are recommendations to repeat what worked well for FISV-01 and some are recommendations 
for changes in the future. The template used for each lesson learned is in the Appendix. 


1 "FASTSAT Project Plan Baseline Controlled R1 Apr 15.doc" 
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Figure 1: FASTS AT HSV-01 
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2.0 Project Management Lessons Learned 


Lesson Learned Title: 

Co-Located, Flat Team Model 

Lesson Learned Submitted Date: 2/22/10 

Lesson Learned Submitted by: Tom Simon 

POC Name for Follow on Discussion: Mark Boudreaux 

POC Email: mark. e.boudreaux(5)nasa. gov 

POC Phone: 256.961.7494 

Overview: 


The FASTSAT FISV-01 team was co-located in one building and based on a level-limited hierarchy. The 
FISV-01 team includes NASA, industry and academia. The co-location and limited hierarchy greatly 
improved team efficiency. 

Discussion: 


During the vehicle design phase, the co-location enabled very fast resolution of questions and issues 
between engineers and the limited hierarchy enabled fast approval between engineers and 
management. During the vehicle fabrication phase, the co-location of all engineers and hardware 
enabled the quick construction of the vehicle without compromising quality assurance. During the 
vehicle testing phase, the co-location and limited hierarchy enabled fast resolution of anomalies. Space 
limitations and other considerations did not allow for having the Attitude Determination and Control 
System (ADCS) team or the Structural analyst to be co-located with the rest of the core team. This 
limitation proved to be surmountable, but resulted in some periods of re-work and waiting. 

Recommendation(s) for Future Projects: 

It is recommended to co-locate and limit the hierarchy as much as possible for future projects. This co- 
location should include the leads for all key subsystems/elements. The FISV-01 project benefited greatly 
from team co-location. 

Evidence of Recurrence Control Effectiveness: 


The FISV-01 project had very little time invested in telecoms or other communications methods utilized 
for complex distributed teams. If future projects determine early in the process that a high percentage 
of time is being spent on telecoms or writing email then co-locating can help increase efficiency. 

Documents Related to Lesson: 

None 
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Lesson Learned Title: 


Personnel Backups 

Lesson Learned Submitted Date: 2/22/10 

Lesson Learned Submitted by: Tom Simon 

POC Name for Follow on Discussion: Mark Boudreaux 

POC Email: mark.e. boudreaux@nasa.gov 

POC Phone: 256.961.7494 

Overview: 


In order to meet project schedule needs on short turn-around projects, it is recommended to have at 
least two people covering all critical roles. If a critical role is met by only a single person then significant 
delays for a short turn-around project like HSV-01 could occur if he/she becomes unavailable either due 
to personal, funding, or organizational priorities. 

Discussion: 


There will be times when personnel become unavailable over the course of any spacecraft development 
effort and having additional qualified personnel capable of supporting should the lead become 
unavailable would minimize the impact on the project. Having two qualified personnel for each critical 
role also will relieve stress on personnel that face hardships and to allow personnel to take annual leave 
and avoid excessive working hours for extended periods of time. In many cases the critical roles in the 
HSV-01 team were more than one person deep. For the cases of two personnel working a similar role 
on HSV-01, schedule gains were often made by concurrent operations which reduced the cost impact of 
the additional personnel. For cases where the critical role was one person deep, this eventually resulted 
in schedule slips and/or overextended personnel. Obviously, having two people up to speed with a "hot 
spare" mentality affects funding assumptions and should be part of the initial planning. 

Recommendation(s) for Future Projects: 

Form the project team with two personnel capable of fulfilling the responsibilities of each critical role. 
Critical role in this case is any role that would impact the project schedule if a person became 
unavailable. 

Evidence of Recurrence Control Effectiveness: 


Budget discussions in the formulation phase, as well as organizational meetings prior to kickoff, need to 
address this "people" issue. Discussion on critical roles and backups prior to the kick off meeting is vital. 
If a schedule impact occurs due to a person being absent for any reason then it should be considered to 
add a person or cross train an existing team member for that role. If a team member is working 
excessive hours for extended periods of time then again it should be considered to add a person or cross 
train an existing team member for that role. 

Documents Related to Lesson: 


None 
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Lesson Learned Title: 


Test Readiness Reviews 

Lesson Learned Submitted Date: 3/15/10 
Lesson Learned Submitted by: Gary Wentz 
POC Name for Follow on Discussion: Tim Smith 
POC Email: tirnothy.a.smith(5>nasa.gov 
POC Phone: 256.961.7651 

Overview: 


Test Readiness Reviews (TRRs) were conducted several times during the development of HSV-01. 
Relevant information was presented summarizing the recent work to prepare for a test and the test 
planned. Additional information, tailoring the procedure review process, and having the procedures 
signed before the review would increase the value of the TRRs for follow on projects. 

Discussion: 


Feedback on the TRRs conducted for FISV-01 was diverse and came from FISV-01 team members and 
review board members. The TRRs were not as detailed technically as many TRRs conducted at MSFC, 
manned or unmanned. In general, this was due to limited time for team members to package technical 
information for the meetings. The value of having a board review the planned test is proportional to the 
detail provided to a reasonable amount of information. For example, a thermal vacuum test TRR could 
discuss just the planned thermal vacuum environment or also discuss the analysis performed to 
generate those planned thermal test environment conditions. The benefits would differ between these 
two options in that the simpler TRR would have the board review the readiness to test under the test 
conditions and the more detailed TRR would review the readiness of the spacecraft to successfully 
operate in flight. The detailed version would help also drive out test-as-you-fly conditions but the 
simple TRR could defer the details to the CDR or another forum, especially for a tailored unmanned class 
D mission. All of the TRRs from FISV-01 concluded with the open action of acquiring the procedure 
signatures. Ideally the procedures would be signed before the review to limit the uncertainty of the 
readiness of the procedure. Flowever, it is not clear that anything tangible is lost by having the 
procedures signed after the TRR as well as it is not clear that any time savings are made by having the 
procedures signed afterwards. 

Recommendation(s) for Future Projects: 

It is recommended to attempt to have the TRR board members be an appropriate subset of the PDR and 
CDR board members or attendees. This would allow detailed information covered at PDR and CDR to 
be referenced at TRRs. It is recommended to discuss the objectives of the test to increase the chance of 
mission success including the background information related to how the test conditions will meet the 
objectives. This will enable the board to assess how well the test will serve to increase the chance of 
mission success which is likely a more appropriate role for the board than simply hearing an overview of 
the conditions selected or reviewing the format of the procedures. Lastly, it is recommended to include 
the TRR expectations in the SEMP, Project Plan, or the Integrated Test Plan. 
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Evidence of Recurrence Control Effectiveness: 

Assuming the TRR content matches the SEMP, Project Plan, or the Integrated Test Plan content 
description, if feedback is received on a TRR that the content was not adequate then the SEMP, Project 
Plan, or the Integrated Test Plan description can be modified to meet the expectations if the change is 
value added. 

Documents Related to Lesson: 

TRR presentations from HSV-01 
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Lesson Learned Title: 


Timely Customer Feedback 

Lesson Learned Submitted Date: 3/18/10 
Lesson Learned Submitted by: Dave Kincaid 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


It is critical to receive timely feedback from the customer upon delivery of products or requests for 
information or direction, especially on short turn-around projects. The penalty for delays in feedback or 
direction can lead to schedule delays and potentially re-work. 

Discussion: 


Receiving feedback on HSV-01 data provided to support the systems engineering tool from STP was not 
always early enough to implement changes and/or new direction to avoid rework and changes. 

FASTSAT had to assume the risk that inputs were acceptable and perform work without customer 
feedback. An example is delivery of the safety compliance data. The safety data for the mission was 
submitted in multiple iterations with no comment received from the STP. If changes had been required 
when the data was finally reviewed, it would have been too late to make any necessary design changes 
and either operational constraints would have been imposed or a waiver to requirements would have 
become necessary. Additional communication issues occurred with late direction of design/test 
requirements that risked causing major rework later in the project. An example is very late review of 
model correlation results that threatened to cause the project to perform another modal survey test 
immediately prior to satellite delivery. 

Recommendation(s) for Future Projects: 

It is recommended that the ICD with the customer be baselined by PDR and that all product or 
procedures submitted for review have agreed upon review due dates to be tracked. It is recommended 
that all design driving inputs required from the customer also be provided by PDR and that safety 
related issues be called out explicitly (not just mentioning the reference document). 

Evidence of Recurrence Control Effectiveness: 


If work is delayed awaiting reviews then the remaining product delivery dates and review periods should 
be readdressed. 

Documents Related to Lesson: 


STP-S26 SPACE VEHICLES AND OSP MINOTAUR IV LAUNCH VEHICLE ICD, 1045-0605 REV B DRAFT 
9 4 09.doc 
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Lesson Learned Title: 


Operational Security Plan 

Lesson Learned Submitted Date: 4/7/10 
Lesson Learned Submitted by: Brandon DeKock 
POC Name for Follow on Discussion: Brandon DeKock 
POC Email: dekockb@saic.com 
POC Phone: 256.213.4757 

Overview: 


The HSV-01 project operated with the intent to follow the Sensitive But Unclassified (SBU) standard 
corresponding to the Air Force's "For Official Use Only" (FOUO) level. This level of security on all 
documents would have led to significant restrictions on communication and data sharing if the 
requirements had been levied in all instances. 

Discussion: 


The electronic communications between FASTSAT personnel and the Air Force personnel often 
contained detailed information regarding the spacecraft design and mission, emailed unencrypted. The 
direction on what was protected varied from time to time. Access to information through a secure 
system (Windchill) was attempted with limited success and sometimes significant delay in receipt. 

Recommendation(s) for Future Projects: 

In order to ensure sufficient OPSEC (Operational Security) in this type of environment, it is necessary to 
convey exactly what information is to be treated as secure. This needs to be done in writing in a specific 
way that can be read and understood consistently by people participating in the project. Follow on 
efforts can break down project content into clear categories as to what is SBU or otherwise and to 
whom these restrictions apply. This information can be captured in the Project Plan, SEMP, or another 
document to be reviewed and discussed with the entire team. This security plan should be negotiated 
with the customer and all parties to assure all understand the cost and benefits of security measures. 

Evidence of Recurrence Control Effectiveness: 


If the team has discussed the rules for keeping information secure upfront, then all are empowered to 
follow up with each other on maintaining the security. If project leadership sees instances of security 
improvements to make then it can be brought up at team meetings without names as examples for all 
to learn. 

Documents Related to Lesson: 


None 
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Lesson Learned Title: 


1 st Generation Spacecraft Using a Faster and Cheaper Process 

Lesson Learned Submitted Date: 2/22/10 

Lesson Learned Submitted by: Tom Simon 

POC Name for Follow on Discussion: Mark Boudreaux 

POC Email: mark.e. boudreaux@nasa.gov 

POC Phone: 256.961.7494 

Overview: 


The FASTSAT FISV-01 spacecraft is a first generation Class D spacecraft produced with the objective of 
being faster and cheaper than previous similar development projects. Many of the components had 
been lab tested but little of the hardware has any flight experience. A simple design and tailored 
development process were implemented to enable the team to produce the spacecraft. 

Ideally, the first generation system would have significant reserves on budget and/or schedule to 
accommodate the development issues that arise when producing new components, subsystems, and 
spacecraft. The second or later generation satellites could then reap the benefits of the first generation 
development and on-ramp additional tailored processes to reduce cost and/or schedule. 

While FISV-01 was able to produce the spacecraft, future first generation projects with little to no 
heritage hardware also need to tailor the process consistent with the class of the hardware and to begin 
the effort with significant budget and/or schedule reserve. 

Discussion: 


The early development process for the FISV-01 spacecraft leveraged heavily the spacecraft design 
worked two years earlier for notional mission requirements. The leveraged design included some 
component level testing and where possible utilized COTS hardware. All phases of the development 
process were compressed relative to many space vehicle development efforts but discipline was 
maintained to retain the intent of each phase and adequate rigor for this Class D mission. 

The potential for any follow on spacecraft to be carbon copies of the first is very low. In reality, the 
potential cost savings for 2 nd generation systems will be somewhere between the cost of a first 
generation copy and the cost of another completely new system. Another cost and schedule savings 
that can be incurred when a team produces a second generation spacecraft is the experience the team 
has from the first spacecraft, even if there are noticeable differences between the two spacecraft. 

One issue not encountered by FISV-01 was personnel burnout due to an extended period at a high level 
of performance. FISV-01 was produced in a year but other projects that would extend to multiple years 
likely will encounter issues with working very long hours for extended periods. 
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Recommendation(s) for Future Projects: 


If many of the components and subsystems have been proven prior to the spacecraft development then 
a faster and cheaper process is likely achievable, especially for Class D spacecraft. If some (or many) 
components or subsystems are not proven then having adequate budget and/or schedule reserves will 
increase the chance for the project to achieve its baseline cost and schedule. It is recommended to 
identify new (no relevant flight experience) technologies, components, and/or subsystems during the 
project definition of the baseline budget and schedule. It is recommended to plan for additional time, 
development, testing, and cost for each new technology, component, and/or subsystem. Identify 
example projects with actual development time and costs to assist in quantifying the schedule and 
budget margin required. Conduct a peer review of the project baseline prior to baseline schedule and 
budget. 

Evidence of Recurrence Control Effectiveness: 


A limited reserve called out for new technologies in the baseline plan may indicate the potential for 
eventual budget overruns and schedule issues. Track the schedule and budget over the course of the 
program with careful attention to the development of the new technologies. 

Documents Related to Lesson: 

None 
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3.0 Systems Engineering Lessons Learned 


Lesson Learned Title: 

Tailored Spacecraft Development Systems Engineering Process 

Lesson Learned Submitted Date: 2/22/10 
Lesson Learned Submitted by: Tom Simon 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david. f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


The FASTSAT FISV-01 spacecraft development effort utilized a tailored process of NPR 7120. 5D. The 
tailored process was assumed in the development of the Project Plan and the Configuration and Records 
Management Plan 2 . This lesson learned input makes suggestions for additional up-front definition of 
the tailored process. 

Discussion: 


When the FISV-01 team was preparing for spacecraft environmental testing, the project temporarily 
halted work due to differences in the expectations from NASA technical authority and HSV-01 project 
personnel. The expectation differences were centralized around the preparation and review of the test 
procedures as well as the amount of successful ambient testing that had been conducted. It is now 
known that more clarity and agreement on the development process and testing should be discussed 
and documented at the start of the project to avoid misunderstandings being discussed at the project's 
most delicate steps. 

The scope of the integrated spacecraft testing was documented in the Integrated Test Plan. 3 Some of 
the details of the integrated testing and the process of on-ramping components to the spacecraft 
integration were presented at team design reviews. In the future, capturing the planned process for 
components to on-ramp from the component developer to a part of the vehicle integration effort will 
make all parties aware of the plans and help expedite project transitions. These details can be captured 
in a Systems Engineering Management Plan (SEMP). 

Capturing the details of the process and testing planned and required for progressing from one 
spacecraft process step to another would also avoid issues on future developments. For example, 
requiring at the project start at least X hours of full spacecraft operation prior to environmental testing 
would help all agree upon the readiness for proceeding to the next step. Informally, the plan was to 
perform rigorous testing to buy down risk, to document any test-as-you-fly exceptions, and to perform 
ambient and environmental testing of all electronics prior to integration on the spacecraft. The 
documented plan included the production of an Avionics Test Bed (ATB) to perform subsystem ambient 
testing, additional details such as utilizing log books to capture component testing and the component 


2 MSFC-PLAN-3563, "FASTSATCMP.doc" 

3 MSFC-PLAN-3564 Draft, "FASTSAT HSV ITP -5-14-09 BL Draft-TS.doc" 
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as-built designs 4 , and for the overall spacecraft to undergo environmental testing. The informal and 
documented plans contributed to the readiness of the vehicle to transition to each development phase. 
All of these process details can be captured in a SEMP. The minimum required testing can be captured 
in the form of an Incompressible Test List (ITL). There were two cases of component or subsystem 
testing not meeting the planned testing prior to vehicle fabrication that led to the spacecraft being re- 
opened after vehicle environmental testing and an ITL would help avoid this in the future. 

There are many organizations with Organizational Work Instructions (OWIs) that cover the process to 
produce Test Preparation Sheets (TPSs), and they share a much in common. However, there are 
differences between the OWIs and some organizations do not have an OWL HSV-01 TPSs were utilized 
for hardware after the hardware had been accepted by the project. The project TPSs were utilized for 
component and subsystem level testing and other tasks directly using hardware up through vehicle 
integration. Some TPSs were produced with time spent planning every step that would be taken with 
the hardware, some steps calling out the recording of data, and some included reviews by other 
technical area personnel and/or line managers. Other TPSs had less details documented prior to testing, 
were by design left open ended to real time develop and write down the steps performed with the 
hardware, and/or were not reviewed by other technical area personnel and/or line managers. While 
there was not a direct correlation between hardware anomalies and the level of detail and review of the 
TPSs, there also was never a significant amount of time required to gather signatures or document TPSs 
in detail prior to testing. In the future, capturing the process for the hardware prior to delivery to the 
project and the OWIs that are authorized for project use after hardware delivery to the project could be 
captured in the SEMP. Additional organizations that wish to write TPSs may produce their own OWIs to 
provide further options if the need arises. 

Recommendation(s) for Future Projects: 

It is recommended that follow on projects produce a detailed Systems Engineering Management Plan 
(SEMP). The SEMP should include the process from requirements to ready for launch, the process from 
the part or component to the integrated vehicle, and the test-as-you-fly exceptions communication and 
review/approval plan. A SEMP does not require the selection of the same process used for Class A 
programs and can still be tailored for the class of the project. Capturing the tailoring in the SEMP will 
help reduce the issues later in the process. It is also strongly recommended that an Incompressible Test 
List (ITL) be produced at the start of the project to capture the required component, subsystem, and 
vehicle testing with details on critical engineering parameters, time, and criteria for passing to the next 
step. Lastly, it is strongly recommended to produce an equivalent to the ATB to enable subsystem 
testing without risking or delaying the vehicle assembly. 

Evidence of Recurrence Control Effectiveness: 


Review the SEMP for the systems engineering process and the test-as-you fly plan. If issues arise 
regarding process or test-as-you-fly exceptions then the SEMP should be updated to avoid additional 
issues. Review the ITL at project reviews to verify all required tests are being performed. If all ITL 
exceptions require Configuration Control Board (CCB) approval then these exceptions can be tracked. 


4 MSFC-PLAN-3563, "FASTSATCMP.doc", page 4 
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Documents Related to Lesson: 


FASTSAT Project Plan Baseline Controlled R1 Apr 15.doc 

Configuration and Records Management Plan, MSFC-PLAN-3563, "FASTSATCMP.doc" 

FASTSAT HSV-01 Integration and Test Plan, MSFC-PLAN-3564 Draft, "FASTSAT HSV ITP -5-14-09 BL 
Draft-TS.doc" 

FISV-01 ITL produced post-development is in the Appendix 
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Lesson Learned Title: 


Integrated Testing for Accelerated Development Projects 

Lesson Learned Submitted Date: 4/5/10 
Lesson Learned Submitted by: Linda Jeter 
POC Name for Follow on Discussion: Linda Jeter 
POC Email: linda.b.jeter@nasa.gov 
POC Phone: 256.544.7392 

Overview: 


FASTSAT HSV-01 was produced at an advanced development pace and using a tailored process. This 
lesson learned submittal includes the issues and recommendations from the organization that was 
responsible for integrated testing during the FISV-01 development. 

Discussion: 


The amount of work required by the test engineer was under estimated for HSV-01 causing excessive 
periods of greater than 40 hours worked per week. To help assess the work involved with integrated 
testing, typical test engineer roles and responsibilities for ES61 are listed here: 

• Develop Integrated Test Plan 

• Integration and Coordination Activities (Planning, Requirements Flow-down Review, Document 
Review, Test Expertise) 

• Review and Coordinate Test Requirements Document Review 

• Coordinate and Conduct Test Readiness Reviews 

• Develop Test Methodology and Test Approach defining needed test resources (this requires 
negotiation with Test Requestors) 

• Develop Test Procedures (table tops, line by line reviews, integrate with system engineers and 
discipline experts) 

• Conduct preliminary Dry-Run Tests to augment test methodology and procedure development 

• Develop Test Preparation Sheets/Procedures 

• Conduct Tests and generate Test Reports 

• Produce, archive, and distribute test data as appropriate to support verification closure 

• Analyze Test Data and Results which will translate to greater Systems Knowledge 

• Coordinate with and respond to Quality Requirements Approval Process 

• Correlate Test Data with Test Findings and Potential Anomalies 

• Support design reviews 

• Ensure adherence to safety and ESD practices comply with specified policies, procedures, 
guidelines, and regulations 

• Support identification of risks 

• Support identification of hazards and controls 

• Participate in Software Review Boards 

• Participate in Configuration Control Boards 

• Support schedule development and monitoring 
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Recommendation(s) for Future Projects: 


The following are recommended for HSV-02 and the rationale is applicable to many short schedule 
projects: 

• Two full time Dynetics test engineers are needed for this effort. One person cannot be expected 
to prepare all the test documentation and conduct all the tests. These engineers should be 
brought in at the beginning/planning stages of the project. 

• The FASTSAT-HSV Mission 2 Test Plan should be made available at CDR for review and comment. 
Assures that up-front planning has been well thought out and all project members are informed. 

• All Payload Teams should be required to conduct and document their subsystem level testing 
consistently instead of uniquely. 

• All test procedures should be completed well in advance of the test in order to give personnel 
required time to review and comment and for corrections to be incorporated. 

• Test Readiness Reviews should be conducted prior to each test 

Evidence of Recurrence Control Effectiveness: 


If the test engineer(s) is (are) consistently needing to work excessive hours to keep up with the schedule 
then the project should re-baseline the schedule or provide additional test support. Excessive hours for 
a critical role like the test engineer can lead to hardware damage and/or personnel injury. 

Documents Related to Lesson: 


None 
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Lesson Learned Title: 


Test As You Fly (TAYF) Exceptions List 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Tom Simon 
POC Name for Follow on Discussion: Tim Smith 
POC Email: timothy.a.smith(5> nasa.gov 
POC Phone: 256.961.7651 

Overview: 


Developing and utilizing a Test As You Fly (TAYF) exceptions list provided significant value to the team as 
a tool to track and communicate differences between testing and flight. 

Discussion: 


The team produced early in the development process the TAYF exceptions list and updated it 
periodically. The team included this list in the discussions at Test Readiness Review (TRR) meetings. The 
list helped the team and technical authority independent reviewers assess the risk of the gaps between 
testing and the planned flight operations. 

Recommendation(s) for Future Projects: 

Produce and periodically update and report a TAYF exceptions list. The owner can be the Chief Engineer 
and the list can be first presented at PDR. It is recommended to share this list with the customer as well. 

Evidence of Recurrence Control Effectiveness: 


If there is a misunderstanding regarding the difference between testing planned and planned flight 
operations then the list needs to be revised. 

Documents Related to Lesson: 


A notional TAYF exceptions list for a future FASTSAT is included in the Appendix 
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Lesson Learned Title: 


Capturing Payload Requirements 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Dave Kincaid 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


The HSV-01 project produced an Operations & Integrations Agreement (O&IA) to capture the spacecraft 
requirements from the experiments and the interface information between the spacecraft and the 
experiments. 

Discussion: 


The O&IAs provided value to the project and this lesson learned includes additional items to verify are in 
the O&IAs on future projects. 

Recommendation(s) for Future Projects: 

The experiment Acceptance Data Package (ADP) needs to be defined in the O&IA so that when the 
experiment is delivered the ADP is complete and delivered at the same time. An in-depth review of the 
O&IAs should be conducted to verify all requirements on the spacecraft and experiments are captured 
up-front. An example is accidentally not asking for the experiments to be cleaned hardware in the 
O&IA. 

Evidence of Recurrence Control Effectiveness: 


Additional items that would be of value in the O&IA may be uncovered at the design reviews if they are 
covered at the design reviews. 

Documents Related to Lesson: 


O&IA for MINI-ME, MSFC-ICD-3555 
O&IA for PISA, MSFC-ICD-3556 
O&IA for TTI, MSFC-ICD-3557 
O&IA for TDS, MSFC-ICD-3558 
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Lesson Learned Title: 


Process Review Team Size Relative to Spacecraft Class 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Tom Simon 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


The review personnel were limited on HSV-01 to often the Chief Engineer, Lead Systems Engineer, and 
personnel critical for that particular document. This limited review process for items such as TDRs, DRs, 
drawings, ECRs, etc helped expedite the process of design and anomaly resolution. 

Discussion: 


The review of designs, anomalies, and changes were intentionally kept simple to expedite the process. 
The Configuration Management Plan included the Configuration Control Board membership of the 
Project Manager, CE, LSE, and S&MA. 

Recommendation(s) for Future Projects: 

For a class D system, it is recommended to continue this reduced review process for day to day issues. 
The SEMP needs to call out the criteria for increasing the required review for major issues and major 
events. 

Evidence of Recurrence Control Effectiveness: 


If the review process is reduced adequately then there will be continued short process turnaround and 
recovery from changes and anomalies. 

Documents Related to Lesson: 


Configuration and Records Management Plan, MSFC-PLAN-3563, "FASTSATCMP.doc" 
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Lesson Learned Title: 


Interface Control Document (ICD) with Launch Vehicle 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Tom Simon 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


The HSV-01 Interface Control Document (ICD) with the launch vehicle was a product to be produced by 
the Space Test Program (STP). This ICD was not signed until after the spacecraft had been fabricated 
and initially tested. Not having a firm ICD risked schedule delays as well as the potential for fabricating 
and testing the spacecraft to fluid requirements. 

Discussion: 


The HSV-01 team worked with a draft ICD with the STP till after the spacecraft was fabricated. There 
were unusual circumstances in that HSV-01 was not baselined as a payload on this mission till late in the 
development process. Lacking solid customer requirements led to late changes in the vibration and 
mass properties testing as well as inconsistencies between the team verification methods and the 
customer required verification methods. 

Recommendation(s) for Future Projects: 

If the customer ICD is not set early enough in the project to support the design and verifications process 
then the HSV-01 lesson learned can be sighted as rationale to reach a baselined ICD. Not achieving a 
baselined ICD puts at risk late and costly changes to the spacecraft development effort. 

Evidence of Recurrence Control Effectiveness: 


Achieve a baselined ICD with the launch vehicle and/or customer by spacecraft PDR. 
Documents Related to Lesson: 


STP-S26 SPACE VEHICLES AND OSP MINOTAUR IV LAUNCH VEHICLE ICD, 1045-0605 REV B DRAFT 
9 4 09.doc 
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Lesson Learned Title: 


Verification Selections 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Tom Simon 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


Verification methods were selected and defined early in the process and overall greatly increased the 
reliability of the spacecraft to meet the requirements. Some of the verifications were based on common 
practices instead of LV ICD or other requirements and in some cases led to inconsistencies between the 
spacecraft RVC verifications and the requirements. 

Discussion: 


The verifications need to be clear in scope with clear ties to the requirements and/or parent documents. 
The verification process utilized by HSV-01 made a very good attempt at both of these fundamental 
concepts of systems engineering. The difficulty came in the limited definition of the requirements and 
required verification methods by the STP. Luckily no major issues occurred because of the limited 
customer inputs early. There were inconsistencies that led to additional testing by HSV-01 instead of 
less testing. For example, the LV ICD required analysis for the vibration verification and the HSV-01 
closure method selected was test. Later, when discussing the vibration test with the customer days 
before the test, a different vibe profile was given in an email as direction for the test. This led to a 
waiver against the HSV-01 verification plan but still was much more useful than the ICD requirement for 
analysis only. 

Recommendation(s) for Future Projects: 

The ICD and other sources of requirements should be baselined in time for the verification plan to 
include all of these requirements and appropriately select verification methods. 

Evidence of Recurrence Control Effectiveness: 


The ICD and other sources of requirements are not baselined by SRR and the verification plan is not 
complete by PDR. 

Documents Related to Lesson: 


STP-S26 SPACE VEHICLES AND OSP MINOTAUR IV LAUNCH VEHICLE ICD, 1045-0605 REV B DRAFT 
9_4_09.doc 

RVC Rev A 080509 w signatures.pdf 
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Lesson Learned Title: 


Launch Vehicle Integrator Involvement Early 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Lisa Watson-Morgan 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


Issues occurred late in development due to differences in expectations between the Launch Vehicle 
integrator (Aerospace Corp.) and the HSV-01 team. The issues could have been avoided if the Launch 
Vehicle integrator had been more involved in the process early in the development. 

Discussion: 


Having independent launch vehicle or mission integrators involved early in the process reduces the risk 
of issues late in the effort. An example is the surprise to the Aerospace team that the modal analysis 
would not be 100% test verified. The FASTSAT plan was to add balance weights and other minor 
changes after performing the modal test that anchored the model. The model was modified based on 
these changes but another modal test was not performed. Aerospace was not prepared for the values 
they received to have been based on a model not completely verified by test. Long discussions were 
required as well as another independent source consulted to close the topic. 

Recommendation(s) for Future Projects: 

Include all launch vehicle and/or mission integrator teams early in the process. 

Evidence of Recurrence Control Effectiveness: 


Roll call at design reviews should disclose the absence of integration teams. 
Documents Related to Lesson: 


None 
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Lesson Learned Title: 


Time Definition 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Tom Simon 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


The HSV-01 team recognized early that it was critical to align the time stamps to compare data from the 
different sources (experiments, spacecraft, and ground). This early work avoided issues once all 
elements were operated together. 

Discussion: 


Failing to sync time across the elements could have led to incorrect decisions during ground tests if not 
done correctly. For example, troubleshooting during thermal vacuum testing was successful in part 
because the experiment, spacecraft, chamber, and ground support equipment clocks were all aligned. 

Recommendation(s) for Future Projects: 

Early in the process define the standard time for all elements from ground testing through launch. 
Evidence of Recurrence Control Effectiveness: 


Include topic in each review and assess compatibility issues. 
Documents Related to Lesson: 


None 
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Lesson Learned Title: 


Tracking All Requirements 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Dave Kincaid 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


Approximately 110 requirements were included in the Missile System Pre-launch Safety Package 
(MSPSP) for HSV-01 but were not tracked or included in the verification plan. In preparation of the pre- 
ship review the team worked hard to close these requirements and luckily no major design aspects or 
tasks were missed. 

Discussion: 


All requirements sources must be tracked. They can be combined in team references to limit the 
number of separate files and even combined with the verification plans to further consolidate the effort. 
HSV-01 had requirements from the MSPSP, RVC (from MSFC or the ICD), and from the software 
requirements document. 

Recommendation(s) for Future Projects: 

List at each review all sources of requirements and the status and plan for closure. 

Evidence of Recurrence Control Effectiveness: 


If all parties are present at reviews then missing requirements sources will be caught and addressed 
early in the effort. 

Documents Related to Lesson: 


None 
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4.0 Engineering Lessons Learned 


Lesson Learned Title: 

Cable Testing Requirements 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Dave Kincaid 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaidgpnasa.gov 
POC Phone: 256.961.7947 

Overview: 


The cable testing requirements for HSV-01 were not completely defined early in the project. This led to 
confusion and some repeat work during development. 

Discussion: 


Issues occurred in the development of HSV-01 cables in that not all design requirements were captured 
in the drawings and some rework and waivers resulted. Issues also occurred in the testing as not 
enough information was listed on the test request or drawing to define the testing to be required and 
again rework was required. 

Recommendation(s) for Future Projects: 

The overall assembly and test of cables as well as exceptions for individual cables should be defined 
prior to tasking anyone to develop the cables. These cable requirements should be vetted through the 
chief engineer, lead systems engineer, the EMI lead, the lead(s) for the components interfaces by the 
cables, and the cable fabrication and test personnel. 

Evidence of Recurrence Control Effectiveness: 


The cable manufacturer or tester does not have the information required for fabrication or testing. 
Documents Related to Lesson: 


None 
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Lesson Learned Title: 


Cable Interconnect Diagram (CID) 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Dave Kincaid 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


There was no Cable Interconnect Diagram (CID) produced for HSV-01. A spreadsheet was utilized to 
capture the connector types, cable length, and other specifications for the flight cables. A CID would 
have helped with confusion that occurred during fabrication and assisted the spacecraft CAD layout. 

Discussion: 


The spreadsheet did capture technical details such as connector type and other technical details but did 
not serve as a tool for enabling all parties to review the overall cable plan. A CID would supplement a 
spreadsheet to allow the big picture to be seen as well as better enable the review of the component 
interface to the cable. A few instances of incompatible pairings occurred and in the future might be 
avoided by implementing a CID. 

Recommendation(s) for Future Projects: 

Include a CID in the plans. A success of FISV-01 was to have a cable lead that helped define and track the 
production of all the cables. Without that cable lead the project would have had significant delays. 

Evidence of Recurrence Control Effectiveness: 


Additional cable interfacing issues. 
Documents Related to Lesson: 


None 
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Lesson Learned Title: 


EMI Cable Requirements 

Lesson Learned Submitted Date: 3/12/10 
Lesson Learned Submitted by: Dave Kincaid 
POC Name for Follow on Discussion: Dave Kincaid 
POC Email: david.f.kincaid@nasa.gov 
POC Phone: 256.961.7947 

Overview: 


EMI requirements were included early in the process of defining cable design and test requirements. 
Having the EMI requirements included early helped achieve many of the intensions of the requirements. 
Additional benefit could have been realized with stronger ties between the requirements and the 
fabrication and test process. 

Discussion: 


The verification plan included all of the recommendations of the EMI team but the final drawings and 
test requests for the cables did not retain all of the requirements to mitigate EMI issues. 

Recommendation(s) for Future Projects: 

Include the EMI lead on cable drawing reviews. 

Evidence of Recurrence Control Effectiveness: 


The cables are not fabricated and tested per the EMI requirements. 
Documents Related to Lesson: 


RVC Rev A 080509 w signatures.pdf 
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Lesson Learned Title: 


Battery Magnetic Dipole Effect on ACS 

Lesson Learned Submitted Date: 3/12/10 

Lesson Learned Submitted by: Dave Kincaid 

POC Name for Follow on Discussion: Brandon DeKock 

POC Email: dekockb@saic.com 

POC Phone: 256.213.4757 

Overview: 


The HSV-01 battery includes magnetic material and potentially could have a non-constant residual 
magnetic dipole that could have kept the ACS from controlling HSV-01 as per the requirements. Future 
project need to be aware of this issue and implement design features to avoid problems. 

Discussion: 


The HSV-01 spacecraft utilizes torque rods as the only method for attitude control. Torque rods operate 
based on utilizes magnetic rods to adjust the spacecraft's orientation relative to the Earth's magnetic 
field. The HSV-01 battery consists of 40 D-size Ni-Cd cells which include significant amounts of iron— 
which is magnetic. There was a concern raised after the spacecraft was assembled that the battery 
magnetic dipole could be changed by the torque rods and then impact the torque rods ability to control 
the spacecraft. Spacecraft magnetics experts from GSFC and JPL were consulted and provided input that 
the battery casing would minimize the battery dipole change to below the concern of HSV-01. 

Recommendation(s) for Future Projects: 

All projects that utilize torque rods, especially if they are the primary control tool, should minimize the 
magnetic material on board the spacecraft. 

Evidence of Recurrence Control Effectiveness: 


Either no mention of this concern at design reviews, meaning the issue was possibly not considered, or 
the detailed modeling will indicate the inability to meet expected pointing requirements. 

Documents Related to Lesson: 


None 


31 


Lesson Learned Title: 


Remote Data Acquisition (RDAQ) Modifications 

Lesson Learned Submitted Date: 3/3/10 
Lesson Learned Submitted by: Dennis Smith 
POC Name for Follow on Discussion: Dennis Smith 
POC Email: dennis.a.smith(5>nasa.gov 
POC Phone: 256.544.3531 

Overview: 


There are changes recommended to the designs of the Remote Data Acquisition (RDAQ) boxes. These 
changes are based on the testing and final planned use of the boxes relative to the initial design and 
plans. 

Discussion: 


Perform specific modifications listed below. 

Recommendation(s) for Future Projects: 

MTD RDAQ Changes) 

Put all 3 axis MTDs in one housing to simplify the assembly process. 

Consider using +28 VDC and a larger current sense resistor. Discuss with ACS lead. 

Look at using 16 bit A/D. Discuss with ACS lead. 

Include capability to auto-calibrate on orbit. This change is highly recommended. 

ADM Changes) 

Look at putting these into the PDB and BCR to simplify the assembly process. 

Look at new open collector digital outputs or possible opto-couplers. This is a required change. 

All RDAQs) 

Consider using software address instead of hardware address. 

Have a 'A second delay on power up for the ADuC842 microcontroller. Make sure this 
accounted for at system level. 

Evidence of Recurrence Control Effectiveness: 


The POC can discuss in detail the issues related to not performing the recommended changes. 
Documents Related to Lesson: 


None 
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Lesson Learned Title: 


Thermal System Lessons Learned 

Lesson Learned Submitted Date: 3/19/10 
Lesson Learned Submitted by: Ken Kittredge 
POC Name for Follow on Discussion: Ken Kittredge 
POC Email: ken.kittredge@nasa.gov 
POC Phone: 256.544.3684 

Overview: 


This input includes general inputs regarding the HSV-01 thermal system. 
Discussion: 


The design inputs listed are applicable to all flight systems, manned or unmanned. 

Recommendation(s) for Future Projects: 

• Make sure ALL sensor data is recorded during thermal vacuum 

• RTDs need to be epoxied in place or the leads need to be staked 

• Thermocouple welder to put leads on heater wire was a great idea 

• Better mechanical guide to install heater shroud around spacecraft for thermal vacuum test 

• Thermal vacuum test heater shroud should be temperature controlled, not voltage controlled 

• Thermal vacuum test should be performed on the component level for all hardware, preferably 

for all without flight pedigree 

• Thermal modeling should be performed of all electronics components to identify local heating 
or other issues 

• Time and money needs to be allocated for post test thermal analysis and model correlation 

• Software needs to be more functionally tested during thermal vacuum to check heater controls 
and to prevent display issues 

• Drawings of the heater installations and heater installation procedures need to be generated so 
anyone can do the installation 


Evidence of Recurrence Control Effectiveness: 


Issues during integrated thermal vacuum testing 
Documents Related to Lesson: 


None 
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Lesson Learned Title: 


Software Development and Testing 

Lesson Learned Submitted Date: 3/16/10 
Lesson Learned Submitted by: Michelle Schneider 
POC Name for Follow on Discussion: Michelle Schneider 
POC Email: Michelle.Schneider@nasa.gov 
POC Phone: 256.544.1535 

Overview: 


Software development is often in a tight predicament because testing of the final software on the flight 
system is late in the project when time and resources are nearly spent. HSV-01 was no different in the 
timing but this first FASTSAT generation taught the team that follow on efforts will need to schedule 
additional time and plan additional resources to fully test the flight and ground software. 

Discussion: 


In hind sight, this class of spacecraft utilizing the same control plan will require more testers to support 
both software testing and hardware testing (such as vibe, thermal vacuum, etc.). There were significant 
impacts to schedule, cost (overtime), and burden on team members in using some of the few software 
development personnel to perform all integrated testing. Utilizing the same team to produce the 
ground and flight software helped assure good communication between the two products but additional 
time was required than planned for integrated testing. 

Recommendation(s) for Future Projects: 

It is recommended to study the time, cost, and process of the FISV-01 software development in 
estimating the cost of follow on efforts. 

Evidence of Recurrence Control Effectiveness: 


Excessive delays and/or costs in software development. 
Documents Related to Lesson: 


None 
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Lesson Learned Title: 


Space Craft Mass Properties Control 

Lesson Learned Submitted Date: 4/12/10 
Lesson Learned Submitted by: Clay Colley 
POC Name for Follow on Discussion: Clay Colley 
POC Email: clay.colley@uah.edu 
POC Phone: (256)824-6570 

Overview: 


Maintaining a good mass properties control program for a new space craft development is paramount 
to the overall success of the program. 

Discussion: 


Early in the FASTSAT-HSV01 Space Vehicle development, sufficient attention to detail was not given to 
the mass properties of the hardware. As a result, a significant amount of "dead-weight" was added to 
the SV to accommodate several different requirements. This added weight could have been allocated to 
additional equipment, redundancy, batteries, payloads, experiments, etc. 

Recommendation(s) for Future Projects: 

For future spacecraft developments, it is recommended that the following guidelines be implemented to 
establish a sound mass properties control program. 

1. AIAA/ANSI R-020A-1999, Recommended Practice for Mass Properties Control for Satellites, 
Missiles, and Launch Vehicles (see Figure 2) 

2. MIL-FIDBK-1811, Mass Properties Control for Space Vehicles 
Evidence of Recurrence Control Effectiveness: 


These processes should be implemented for every hardware development program. Once 
implemented, the design engineers can quickly assess the mass properties of the vehicle and supply 
accurate information to the other disciplines. 

Documents Related to Lesson: 


Documents listed above. Point of contact information is: 
Clay Colley 

Principal Research Scientist 
UAHuntsville 
(256) 824-6570 (Office) 
clay.colley@uah.edu (Email) 
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MASS PROPERTIES 
(PHASES OF DEVELOPMENT) 



Phase of Program 

Design Mass Growth Allowance Contractor Limit ^*IOC Limit 


Figure 2: Example progression of mass properties from AIAA/ANSI R-020A-1999 
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5.0 Appendix 

Lesson Learned Title: 

Lesson Learned Template 

Lesson Learned Submitted Date: 
Lesson Learned Submitted by: 

POC Name for Follow on Discussion: 
POC Email: 

POC Phone: 

Overview: 


(Provide a one or two sentences stating the single most important finding. Be sure to provide the 
"cause and effect" relationship.) 

Discussion: 


(Describe the situation, giving a complete, concise account of the findings as they relate to the specific 
situation, procedure or design. Describe what went right or wrong and why. This section usually 
consists of one to three paragraphs.) 

Recommendation(s) for Future Projects: 

(This part of the lesson learned must provide the reader with a course of action and tell who should take 
what action. Identify when during the project the suggested action should take place. This block should 
answer the questions "Who, What, When.") 

Evidence of Recurrence Control Effectiveness: 


(Provide the method for future projects to determine if this issue is re-occurring.) 
Documents Related to Lesson: 


(Provide document names, location(s), and POCs.) 
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HSV-01 Test As You Fly (TAYF) Exceptions List 


The following is the HSV-01 TAYF list 

• Spacecraft has been powered from Mobile Checkout System (MCS) power using EGSE cable 
instead of solar power. The spacecraft has been powered during testing from the power supply 
that is a part of the MCS. This testing has demonstrated the charging of the flight battery and 
the satellite has been powered from the battery numerous times. The solar clips have been flash 
tested in the LAPSS facility, and functional aliveness of the clips integrated on the satellite has 
been shown in pre- and post- vibration functional testing, pre- and post-unpowered EMI testing, 
and pre- and post-TVAC testing. The functional aliveness tests include verification of nominal 
current production by the solar panels and verification of current output from the Battery 
Charge Regulators (BCRs) to the battery on board the spacecraft. The satellite could not be 
powered by the solar clips in the thermal vacuum chamber because the thermal shroud covers 
satellite, and cannot be powered for testing using the solar clips without a realistic sun source. 

o Future plans: Solar clip aliveness tests will be performed in functional checkouts before 
and after shipment of the satellite to the launch facility. 

• Flight GSE cover plate was not installed during unpowered EMI and TVAC testing. This plate 
covers the area where the EGSE cable from the MCS power supply connects to the satellite and 
cannot be installed while running the satellite from the MCS power supply. The plate was 
installed during vibration testing, and given the static nature of the plate (closeout panel), this is 
sufficient to demonstrate readiness for flight. 

o Future plans: No additional testing for this exception. 

• Changed fasteners on Flight GSE cover plate to make them captive. Since this plate is installed 
on the satellite as part of the satellite closeout process after the satellite is installed on the 
Multi-Payload Adapter (to enable the Battery Arming Plug to be installed on the satellite as late 
as possible), the decision was made to make the fasteners captive to the plate. This decision was 
made after the completion of environmental testing in a "scrub" of the ground operations 
procedures. The fasteners are the same size as the ones used during vibration testing. 
Additionally, the nature of the plate makes it necessary to be able to "late install", and non- 
captive fasteners (and hardware in general) are being minimized by FASTSAT. 

o Future plans: No additional testing for this exception. 

• "Beginning of Life (BOL) Test Configuration Plug" has been installed during all powered 
testing. The flight configuration does not include the "BOL Test Configuration Plug". The "BOL 
Test Configuration Plug" allows the satellite to be powered bypassing the 30 minute wait time 
that will be used on-orbit after initial ejection from the launch vehicle. Before the EGSE cover is 
installed and the satellite is launched, the flight "Test Configuration Plug" will be installed. 

o Future plans: The wait time requirement will be tested prior to shipment to the launch 
site with the flight "Test Configuration Plug" installed to close an open verification 
item. 

• Flight Test Configuration Plug and Arming Plug not installed during vibration testing. These 
two low mass plugs were not installed during the integrated spacecraft random vibration 
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testing. The reason for this is that installing them in the test configuration of the Motorized Light 
Band (MLB) without the striker plate installed would result in the satellite powering up 30 
minutes after the plug installation. Since our vibration environment is an unpowered satellite, 
the decision was to leave these plugs out. They are low mass (both are less than lounce apiece) 
and will be installed late in the flow with stycast to stake them. They are also contained by the 
GSE plate in their flight configuration. 

o Future plans: A fit check of these plugs will be performed as well as functional testing, 
but no vibration test with the plugs installed will be performed. 

• Motorized Light Band (MLB) Configuration differences during testing. The bottom half of the 
MLB was attached to the upper half in the test configuration for both the vibration testing and 
the TVAC testing. The flight switches were configured to post-separation condition to enable 
powering of the satellite (striker plate removed). The stowed/launch configuration has been 
tested to verify the satellite does not power up when the switches are depressed. 

o Future plans: The final flight stowed configuration will be verified at the launch site. 

• NanoSail-D (NSD) will not be installed in the Poly-Pico Orbital Deployer (PPOD) until 
integration at the launch site. NSD was integrated at ARC to the experiment bus in February, so 
the full-up NSD (with experiment bus) was not available for testing with the FASTSAT bus. 
Environmental testing of the NSD was performed separate from the satellite. A mass simulator 
(mass of integrated NSD) was installed in the PPOD for satellite vibration testing. 

o Future plans: No integrated testing of NSD installed in the PPOD on the satellite is 
planned. FASTSAT only provides a launch/pre-deployment stowage location for the 
NSD - it provides no other services to the NSD. 

• Attitude Determination and Control System hardware and software pre-flight performance 
testing is limited due to ground based configuration. Testing accomplished to date has 
primarily been conducted at the component-level and in the Avionics Test Bed (ATB). All 
attitude determination and control hardware has been integrated and powered up on the 
satellite. The full testing of attitude control and the star tracker is limited on earth. 

o Future Plans: The ACS software (part of software load 3.x.x) will be run on the satellite 
(with 1-g limitations) in an ACS End-to-End Test. The pre-launch planned tests include 
full attitude determination with GPS, Magnetometer, and Sun Sensors. The attitude 
control function will exercise all pointing modes, verifying attitude guidance, and 
torquer commands will be logged to verify control algorithms. The only untested 
element will be full rotation of the spacecraft in response to torquers, which can only 
be performed in orbit. 

• Post-environmental test hardware modifications - (1) MTD RDAQ "stack" During component- 
level residual magnetic testing, it was determined that unacceptable pointing errors are 
introduced by the Magnetic Torque Drive (MTD) RDAQs due to current non-linearity, 
temperature dependence and incomplete de-gaussing of the torque rods. To address these 
errors hardware and firmware changes were made for all three MTD RDAQs. A resistor (same 
physical size) was changed to limit input current to +/-100mA (from 400 mA). A short jumper 
wire (~0.75 inch) was installed to help adjust for D/A offset. The firmware was changed to alter 
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the de-gaussing routine. Changes were performed and validated on engineering hardware. 
Testing of flight modifications included workmanship vibration and thermal cycling of the MTD 
RDAQ stack, during which the performance of each RDAQ was characterized over the 
temperature range. 

• Post-environmental test hardware modifications - (2) Transceiver swap-out. The original 
transceiver in the spacecraft experienced degraded performance during the second integrated 
satellite thermal vacuum test. The degradation manifested itself in the way the waveform 
looked and failure to lock at the 10 Kb, 250 Kb, and 500 Kb downlink data rates at temperatures 
below ambient. Consultation with the manufacturer of the transmitter indicated some vacuum 
conditions had resulted in degraded performance of transmitters like those installed in the 
original transceiver. The spare transceiver has a "new design" transmitter that replaced the 
suspect design transmitter. The spare transceiver was vibration tested to workmanship levels 
and subjected to 4 thermal vacuum cycles. Performance was per specification during testing and 
at the conclusion of testing. 

The work to remove and replace the transceiver and the MTD RDAQ stack was performed at the 
same time. The solar clip on the -y face of the removed to permit access to this area. Thirty-four 
#10-32 fasteners and 2 d-connectors were disconnected to enable removal of the solar clip. All 
connectors and fasteners were reinstalled per print (torqued to the same values as before and 
staked with stycast). 

o Future Plans: Perform functional testing of the transceiver and MTD RDAQs in the 
integrated satellite, performing functional checkouts of all broken/re-made interfaces, 
including functional testing of the solar clips. 

• Hardware limitations during thermal vacuum and EMI testing. The GPS receiver was only 
powered up in TVAC testing. "Repeater" testing has been performed in the Avionics Test Bed 
(ATB). Neither the PPA nor the EOL BRICs were operated during TVAC or during powered EMI. 
These devices are hardware devices that operate for less than two seconds on-orbit and are 
"one-time operation" devices. Component-level thermal testing of these RDAQs and post- 
environmental testing to demonstrate functionality has taken place following each of the 
environmental tests to date. Satellite unpowered EMI testing has been performed to verify the 
satellite would not power on before commanded due to EMI expected at Kodiak and during 
launch. 

o Future Plans: "Repeater" testing will be performed on the satellite. Functional testing 
following powered EMI, thermal vacuum, and post shipment to the launch site will 
demonstrate hardware and functionality. 

• During the pre-flight test and verification process the following experiment "deltas" exist 
which remain "exceptions" prior to launch. 

o TDS cover is in place for cleanliness and to provide a consistent image. This cover was 
removed for vibration testing. 
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■ Future Plans: Remove cover prior to launch (red-tag item). 

o The GSE cover is on PISA - this allows the antenna to be looking at a known calibrated 
source and has been on throughout during functional testing. This mirrors the 
configuration that PISA used during TVAC testing at GSFC. The GSE cover was removed 
for vibration testing. 

■ Future Plans: Remove cover prior to launch (red-tag item). 

o MINI-ME has a safing plug installed to minimize high voltage operations at the 

instruction of the PI. The safing plug was removed during vibration testing (each axis) 
and re-installed during functional testing. 

■ Future Plans: Remove safing plug (red-tag item) prior to launch. 
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HSV-01 Incompressible Test List (ITL) Produced Post-Development 


ITL# 

ITL Category 

ITLObjective(s) 

Test# 

Test 

1.0 

Component and 
Subsystem Testing 

Verify functionality of components under 
ambient conditions and then mission 
environmental conditions. Heritage hardware 
testing can be less than that of non-heritage 
hardware. "Active components" includes 
electronics boxes and non-static mechanical 
components. 

1.01 

Functional testing of active components 

1.02 

Random vibe test of active components 

1.03 

Thermal vacuum vibe test of active components 

1.04 

Acceptance functional test of active components 

Verify subsystem functionality prior to vehicle 
integration. 

1.05 

Functional testing of active subsystems 

2.0 

Experiment/Payload 

Testing 

Verify payload/experiment functionality under 
ambient and then mission environmental 
conditions. 

2.01 

Experiment/payload acceptance functional test 

2.02 

Experiment/payload fit check 

2.03 

Experiment/payload random vibe test 

2.04 

Experiment/payload thermal vacuum vibe test 

3.0 

Spacecraft Integrated 
Hardware Testing 

Verify spacecraft hardware properties and 
functionality. 

3.01 

Spacecraft full functional test, including 
actuation/deployments/etc 

3.02 

Spacecraft mass properties test 

3.03 

Spacecraft modal test 

3.04 

Spacecraft fit check with LV 

3.05 

Spacecraft alignment tests 

3.06 

Spacecraft EMI test 

3.07 

Spacecraft EMC test 

3.08 

Spacecraft vibration test 

3.09 

Spacecraft acoustic test 

3.10 

Spacecraft shock test 

3.11 

Spacecraft thermal vacuum test 

3.12 

Spacecraft thermal balance test 

3.13 

Spacecraft RF compatability test 

3.14 

Extended duration spacecraft testing 

4.0 

Software Testing 

Verify flight and ground software functionality. 

4.01 

Flight software checkout testing of all 
modules/functions 

4.02 

Flight software and experiment/payload software 
testing 

4.03 

Ground software checkout testing of all 
modules/functions 

4.04 

Flight software reload test 

4.05 

Validation of all flight software telemetry 
measurements 

4.06 

Validation of data to ground in files similar to 
mission instead of 100% real-time data 

5.0 

Integrated Hardware and 
Software Testing 

Verify hardware and software integrated testing 
in the final configurations. 

5.01 

Spacecraft full functional test with final flight 
software 

5.02 

Spacecraft full functional test with final flight 
software and final ground software 

6.0 

Mission Sequence Testing 
(MST) 

Test planned operations for nominal and off- 
nominal conditions. 

6.01 

Mission Sequence Test (MST) for separation/tipoff 
and initial power up 

6.02 

Mission Sequence Test (MST) for nominal 
operations with experiments 

6.03 

Mission Sequence Test (MST) for contingencies 

6.04 

Mission Sequence Test (MST) for stretch goals 

7.0 

Launch Site Testing 

Verify spacecraft aliveness at launch site. 

7.01 

Launch site vehicle aliveness test prior to LV 
installation 

7.02 

Launch site vehicle aliveness test after installation 
with LV 


Table 1: Notional Future FASTSAT ITL 
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